Menedżer modułów w PrestaShop wyrzuca błąd XML? Poniżej wyjaśniamy, dlaczego tak się dzieje i w jaki sposób skutecznie to naprawimy – bez konieczności aktualizacji sklepu ani ingerencji w bazę danych.
Najważniejsze z nich to:
Błąd najczęściej pojawia się bezpośrednio w panelu administracyjnym – w zakładce Module lub po wejściu do Menedżera modułów. Komunikaty mogą wyglądać następująco:
PrestaShop wysyła zapytania HTTP do API PrestaShop Addons, aby pobrać aktualne listy modułów. Przykładowy endpoint wygląda tak:
Sklep oczekuje odpowiedzi w formacie XML. Problem pojawia się, gdy:
Co może przestać działać w panelu:
Przed wprowadzeniem jakichkolwiek zmian warto sprawdzić, co aktualnie znajduje się w plikach. Przez SSH wykonujemy:
Jeśli plik jest pusty, zawiera HTML (np. stronę błędu 503) lub JSON zamiast XML – to właśnie jest źródło problemu.
Najszybsze rozwiązanie to zastąpienie zawartości problematycznych plików minimalnym, poprawnym XML-em. Przez SSH wykonujemy:
Można też wgrać pliki ręcznie przez FTP. Zawartość każdego z nich powinna wyglądać tak:
Aby trwale zablokować próby pobierania XML z API Addons, tworzymy override klasy Tools. Tworzymy plik:
O następującej zawartości:
Właściwość $is_addons_up = false sprawia, że PrestaShop nie będzie próbował łączyć się z API Addons – a co za tym idzie, nie będzie pobierał ani nadpisywał plików XML.
Po utworzeniu pliku override czyścimy cache. Dla PrestaShop 1.7 / 8.x:
Można też wyczyścić cache z poziomu panelu administracyjnego: Zaawansowane > Wydajność > Wyczyść cache.
Jeśli nie chcemy korzystać z override, można ustawić plikom XML prawa tylko do odczytu. PrestaShop nie będzie mógł ich nadpisać:
Warto wiedzieć, że w środowisku produkcyjnym większość tych funkcji i tak nie jest używana na co dzień:
Rekomendowane kroki:
Kontakt
Czym są pliki XML w katalogu config/xml/?
PrestaShop przechowuje lokalnie kilka plików XML, które odpowiadają za działanie sekcji Moduły > Menedżer modułów w panelu administracyjnym. Pobierane są cyklicznie z zewnętrznego API PrestaShop Addons i zapisywane w katalogu:config/xml/- must_have_modules_list.xml – lista modułów oznaczonych jako „must have” przez PrestaShop
- modules_native_addons.xml – lista modułów natywnych dostępnych w Addons
- default_country_modules_list.xml – moduły sugerowane dla konkretnego kraju
- trusted_modules_list.xml – lista zaufanych modułów weryfikowanych przez PrestaShop
Jak wygląda błąd XML i gdzie się pojawia?
Błąd najczęściej pojawia się bezpośrednio w panelu administracyjnym – w zakładce Module lub po wejściu do Menedżera modułów. Komunikaty mogą wyglądać następująco:Error found : Start tag expected, '<' not found in must_have_modules_list.xml file
Error found : Start tag expected, '<' not found in modules_native_addons.xml file
Error found : Start tag expected, '<' not found in default_country_modules_list.xml fileHinweis
Błędy te pojawiają się w PrestaShop 1.7 oraz PrestaShop 8.x. W starszych wersjach 1.6 mechanizm działa podobnie, choć lokalizacja niektórych plików może się różnić.
Skąd bierze się ten błąd?
PrestaShop wysyła zapytania HTTP do API PrestaShop Addons, aby pobrać aktualne listy modułów. Przykładowy endpoint wygląda tak:https://api.addons.prestashop.com/?version=1.7.8.x&method=listing&action=must-have- API Addons zwraca odpowiedź w innym formacie (np. JSON lub stronę błędu HTML)
- połączenie z API jest zablokowane przez firewall lub konfigurację serwera
- serwer sklepu nie ma dostępu do zewnętrznych zasobów (brak wychodzącego ruchu HTTP/HTTPS)
- API Addons jest chwilowo niedostępne lub zwraca timeout
- wersja PrestaShop jest zbyt stara i nie jest już obsługiwana przez API
Czy błąd wpływa na działanie sklepu?
Erfolg
Frontend sklepu, koszyk, zamówienia, płatności i wszystkie procesy zakupowe działają normalnie. Błąd dotyczy wyłącznie panelu administracyjnego – konkretnie sekcji zarządzania modułami.
- lista rekomendowanych modułów
- sekcja „must have” w menedżerze modułów
- marketplace Addons dostępny z poziomu admina
- sugestie modułów dla kraju
- wolniejsze ładowanie strony Moduły (timeout przy próbie połączenia z API)
Krok 1 – sprawdzenie zawartości plików XML
Przed wprowadzeniem jakichkolwiek zmian warto sprawdzić, co aktualnie znajduje się w plikach. Przez SSH wykonujemy:cat config/xml/must_have_modules_list.xmlTipp
Do sprawdzenia zawartości pliku można też użyć menedżera plików w panelu hostingowym (np. Hestia CP, cPanel) lub klienta FTP – nie jest wymagany dostęp SSH.
Krok 2 – podmiana plików na poprawny XML
Najszybsze rozwiązanie to zastąpienie zawartości problematycznych plików minimalnym, poprawnym XML-em. Przez SSH wykonujemy:echo '<?xml version="1.0" encoding="UTF-8"?><modules/>' > config/xml/must_have_modules_list.xml
echo '<?xml version="1.0" encoding="UTF-8"?><modules/>' > config/xml/modules_native_addons.xml
echo '<?xml version="1.0" encoding="UTF-8"?><modules/>' > config/xml/default_country_modules_list.xml
echo '<?xml version="1.0" encoding="UTF-8"?><modules/>' > config/xml/trusted_modules_list.xml<?xml version="1.0" encoding="UTF-8"?>
<modules/>Warnung
Samo zastąpienie plików rozwiąże problem tymczasowo. PrestaShop przy kolejnym odświeżeniu strony modułów spróbuje ponownie pobrać dane z API i może nadpisać pliki błędną odpowiedzią.
Krok 3 – trwałe rozwiązanie przez override klasy
Aby trwale zablokować próby pobierania XML z API Addons, tworzymy override klasy Tools. Tworzymy plik:override/classes/Tools.php<?php
class Tools extends ToolsCore
{
protected static $is_addons_up = false;
}Po utworzeniu pliku override czyścimy cache. Dla PrestaShop 1.7 / 8.x:
rm -rf var/cache/dev/*
rm -rf var/cache/prod/*Infos
Po zastosowaniu override sekcja modułów nadal działa w pełni – można instalować, odinstalowywać i aktualizować moduły z pliku ZIP. Wyłączona zostaje jedynie integracja z marketplace Addons w panelu admina.
Alternatywa – blokada zapisu do plików
Jeśli nie chcemy korzystać z override, można ustawić plikom XML prawa tylko do odczytu. PrestaShop nie będzie mógł ich nadpisać:chmod 444 config/xml/must_have_modules_list.xml
chmod 444 config/xml/modules_native_addons.xml
chmod 444 config/xml/default_country_modules_list.xml
chmod 444 config/xml/trusted_modules_list.xmlHinweis
Metoda z chmod jest prostsza, ale nie eliminuje prób połączenia z API – PrestaShop nadal będzie je wykonywał, co może spowalniać ładowanie strony modułów. Override klasy Tools jest rozwiązaniem czystszym technicznie.
Czego nie tracimy po wyłączeniu Addons API?
Warto wiedzieć, że w środowisku produkcyjnym większość tych funkcji i tak nie jest używana na co dzień:| Funktion | Po wyłączeniu API |
| Frontend sklepu | Działa bez zmian |
| Zamówienia i koszyk | Działa bez zmian |
| Instalacja modułów z ZIP | Działa bez zmian |
| Aktualizacje modułów | Działa bez zmian |
| Marketplace Addons w adminie | Niedostępne |
| Rekomendacje modułów „must have” | Niedostępne |
| Sugestie modułów dla kraju | Niedostępne |
Kiedy błąd może powrócić?
Jeśli zastosujemy wyłącznie podmianę plików bez override lub chmod, błąd może powrócić po:- odświeżeniu strony Menedżera modułów
- uruchomieniu crona PrestaShop
- aktualizacji PrestaShop
- wyczyszczeniu cache
Zusammenfassung
Błąd XML w panelu PrestaShop to problem komunikacji starej wersji sklepu z API Addons – nie jest to awaria serwera, problem z bazą danych ani obecność złośliwego oprogramowania. Sklep działa normalnie. Rozwiązanie jest szybkie i nie wymaga aktualizacji PrestaShop.Rekomendowane kroki:
- Sprawdzenie zawartości plików w config/xml/
- Podmiana plików na minimalny poprawny XML
- Dodanie override klasy Tools z $is_addons_up = false
- Wyczyszczenie cache PrestaShop
Kontakt
